Glossary

Absolute Project is a project that is set up outside of a Working Environment. SNiFF+ therefore references these projects using an absolute path.

Adaptor is the specific implementation of a SNiFF+ interface. For example, the generic CMVC interface of SNiFF+ has adaptors for CMVC tools. The SNiFF+ debugger interface has adaptors for debuggers (gdb, dbx, etc.).

Branches occur in a version tree when you create new versions of a file from the middle instead of the end of the tree. Basically, SNiFF+ allows you to perform the same operations on branches that you can perform on the main trunk of a version tree.

Browser is a tool that is used for viewing (and not editing) data only. SNiFF+ offers several browsers like the Symbol Browser, the Class Browser and the Hierarchy Browser. The information displayed in browsers can be filtered in several ways.

Build is the process of creating the targets of a project. The build steps are usually described in makefiles which are executed by programs like Make. A build can involve translations of source files and the construction of binary files by compilers, linkers and other tools.

Check-in is the process of checking in a working file from a working environment, thereby creating a new version of the file in the Repository. A complete project can be also checked in. Typically, after a file has been checked in, locks made on the file are removed from the Repository. A file check-in can be associated with a change set. Note that SNiFF+ doesn't check in files itself. It delegates the operation to your underlying CMVC tool (by means of CMVC adaptors).

Check-out is the process of creating an editable working file in the working environment from a specific version of the file in the Repository. Depending on what actions are planned with the file, a lock of that file in the Repository is set. A check-out can be associated with a change set. SNiFF+ delegates the actual check out operation to your underlying CMVC tool (by means of CMVC adaptors).

CMVC is the abbreviation for configuration management and version control.

Concurrent lock is a lock that, unlike an exclusive lock, does not prevent others from locking the same version of a file. Versions that are concurrently locked must be merged back into the Repository.

Configuration is a coherent and consistent state of a system or project. A configuration has a name and refers to specific versions of files in the Repository. Typically, a configuration is a buildable state of a system.

Configuration management is the process of controlling and administrating the components of configurations. Configuration management includes the freezing (baselining) of configurations.

Default Configuration is the version of your software system that you work on. You can set your Default Configuration when you define your working environments. SNiFF+ uses your Default Configuration for the default value when you choose one of the various version control commands (e.g., checking out file versions, locking/unlocking file versions), and during the updating of Shared Source and Private Working Environments. Source files are made up-to-date with respect to the Default Configuration.
By default, the

HEAD version of your software system is the Default Configuration for your Private Working Environment.

Dependency as used in Make is a relationship between two files that says that one file must be updated or rebuilt when the other one changes. In the Makefile, a dependency is a word listed after the colon ':' on the same line as a target. Source-level dependencies can be extracted from source code and are typically stored in dependency files. SNiFF+ generates dependency files that are included by Makefiles as part of its Make Support feature. Build-order dependencies must always be specified explicitly.

Derived file is a file that can be generated (derived) from another file. A typical example of a derived file is an object file that is generated from a source file after compilation.

Documentation template is a file that describes the structure and content of documentation frames. Each documented symbol type has its own documentation template. When documentation for a symbol is generated, SNiFF+ creates a documentation frame for the symbol. You can customize documentation templates.

Documentation frames are created when you tell SNiFF+ to document a symbol in your source code. Empty documentation frames represent the initial, undocumented state of a symbol's documentation. The structure and content of documentation frames are described by documentation templates.

Editor is a tool that is used for both viewing and changing data. SNiFF+ offers a number of editors (e.g., Source Editor and Project Editor). Tools that just show, but do not modify data, are called browsers.

Exclusive lock is set on a version in the Repository when a file is checked out for modification. Each version can have only one exclusive lock, thus preventing other developers from modifying the same version.

File is a component of a project. Each file is associated with a file type.

File type is associated with a file and determines several attributes of the file. Every file of a SNiFF+ project has a file type. SNiFF+ comes with a set of predefined file types, but there can be any number of file types in a project. Examples of file types are C++ implementation, C++ header, makefile, yacc source, shell script, etc. A file's file type determines how SNiFF+ treats the file and what operations may be performed on the file.

Freezing a configuration is the process of creating a "virtual snapshot" of the system (or, to be exact, of its source files) at special times during the software development process. You do this in SNiFF+ by associating the current state (configuration) of all project source files with a single symbolic name. The process of creating a single configuration and associating it with a symbolic name is called "freezing a configuration".

HEAD is the latest version on the trunk or branch of a file's version tree.

History reflects all the different versions of a file and is stored in the Repository file.

Inheritance is a directed relationship between two classes in which one class inherits the attributes of another classes. In single inheritance, a class inherits from only one class. Multiple inheritance means that a class inherits from several classes.

INIT is used by SNiFF+ as name to refer to the initial version of a file in the Repository. The

INIT version is created when a file is checked into the Repository for the first time.

Interfaces are intermediaries between two components or tools or between the user and the machine. SNiFF+ uses interfaces to interact with the outside world and external tools. A SNiFF+ interface can have multiple specific implementations. called adaptors. For example, the generic CMVC interface of SNiFF+ has adaptors for CMVC tools. The SNiFF+ debugger interface has adaptors for debuggers like gdb and dbx.

Lock is a mechanism that controls access to versions of files in the Repository. SNiFF+ distinguishes between exclusive locks (only one developer can modify a specific version) and concurrent locks (multiple developers can simultaneously modify the same version).

Locking is the process of setting locks.

Main branch is the starting branch of a file's version tree. Unless otherwise specified by your default version control configuration, the main branch is the default branch for CMVC operations.

Make is the program that reads Makefiles and drives the building process. SNiFF+ integrates a wide range of different Make implementations.

Makefile is a text file read by Make programs that describes the building of targets. A Makefile contains source-level dependencies and build-order dependencies. As part of its Make Support feature, SNiFF+ generates Make Support Files that contain both kinds dependency information.

Make macro is a variable in a Makefile which can be assigned a string value. The value can be set in the Makefile itself, on the command line or by setting an environment variable with the same name. SNiFF+ uses Make macros to separate general, platform-specific, project-specific, and team-specific information. A coherent, generic and extendable set of Make macros is part of SNiFF+'s Make Support feature.

Make Support File is either generated out of the project's source code or supplied with the SNiFF+ package. Make Support Files contain the following information: generic Make rules, source-level dependencies, build-order dependencies, project-specific macros and platform-specific macros.

Merge is the process of combining the contents of two or more files into a single file. Typically, the files involved in a merge are versions of a single Repository file. A merge can be done automatically, but often requires manual intervention to resolve conflicts. SNiFF+'sDiff/Merge tool is used for merging files.

Object file is a derived file that is generated from source code after a build. SNiFF+ maintains a list of all object files for a project and generates a make support file containing this list.

Shared Object Working Environment is a working environment that, in contrast to a source working environment, stores only platform-specific files. Typically, a Shared Object Working Environment stores all object files of a project. A Shared Object Working Environment always accesses a corresponding Shared Source Working Environment. As a result, it must also have the same directory structure as the common (accessed) part of the corresponding Shared Source Working Environment.

Obsolete file is a file that is located in a project's directory but is not part of any SNiFF+ project. Obsolete files are generated by continuous development and changes to the project structure and should be deleted from time to time in order to keep a project's working environment clean. SNiFF+ Make Support feature offers mechanisms for finding and deleting obsolete files.

Owner is a developer that owns a file or a working environment.

PDF see Project description file (PDF).

Platform is the combination of architecture, vendor and operating system. SNiFF+ executes on all supported platforms. Object working environments are platform-specific. The targets of SNiFF+ projects can be platform-specific. SNiFF+ executes the

sniff_arch script to determine which platform its running on.

Preferences are the customizable attributes of SNiFF+. SNiFF+ supports user-level and site-level preferences. Most preferences can be edited with the Preferences dialog.

Private Working Environment (PWE) is a directory tree that contains the projects and working files of a single developer. A Private Working Environment is accessible and changeable by only one developer. All check-in and check-out operations work with files in the Private Working Environment. A Private Working Environment must have the same directory structure as the common (accessed) part of the corresponding Shared Source Working Environment.

Projects consists of files, attributes and subprojects. A project is the main organizational element in SNiFF+ and is described by a Project Description File (PDF). Project hierarchies can be built by adding one project to another project, thus creating a superproject-subproject relationship between the two projects.

Project Description File (PDF) is the file that describes a project's attributes, structure and contents. A PDF is a structured ASCII file that is created, saved and opened by SNiFF+. PDFs can also be generated with the

sniff_genproj batch program.

Project history is the set of all configurations of a project.

PWE see Private Working Environment (PWE).

RCS is a widely used revision control system that is licensed under the GNU public license. SNiFF+ integrates RCS as an underlying version control tool and also supplies it with the package.

Repository contains all Repository files of version-controlled projects. The Repository is typically directly accessed only by the managing CMVC tool and usually stores the different versions in an optimized delta format to save space.

Repository file is the file in the Repository that saves all the complete version tree of a file.

Root directory see Working environment root directory.

SCCS is the widely used source code control system that is supplied with most Unix implementations. SNiFF+ integrates SCCS as an underlying version control tool.

Shared file is a source file that is shared among the members of a development team. Shared files are located in a Shared Source Working Environment.

Shared working environment (SWE) is a directory tree that contains the files (source or object) shared in a team. Shared working environments are accessed (shared) among several developers in a team. There are two types of shared working environments: Shared Source and Shared Object.

Shared Source Working Environment (SSWE) is a shared working environment that contains source files only. Typically the platform-specific files are contained in a corresponding Shared Object Working Environment.

SOWE see Shared Object Working Environment (SOWE).

SSWE see Shared source working environment (SSWE).

Symbol is a named language construct in the source code.

Symbol information is extracted from the source files of a project. A project's symbolic information is stored in a Symbol Table, which is saved to disk and transparently managed by SNiFF+.

Symbol Table is the information base that contains information about the declaration, definition and use of named program elements such as classes, methods, variables and functions of a project. Each project has its own Symbol Table that is generated and maintained by the appropriate language parser. Symbol Tables are kept in memory and are persistently stored to disk.

Symbolic link is a symbolic reference to a file in the Unix file system. In contrast to hard links, symbolic links can span different file systems.

Target is the result of a build process. SNiFF+ allows multiple targets to be built in a single project.

Team is a group of software developers working together on a set of projects and sharing a set of common working environments.

Update is the process of checking out all new

HEAD versions of projects in a working environment. Typically, updates are done automatically overnight and are followed by automatic builds of all Shared Object Working Environments and Private Working Environments.

VCS is the abbreviation for version control system.

Version is a particular revision and an element of the version tree of a file. A version is created by checking in a working file. The version of a file that you check out is your working file.

Version control is the process of managing and administrating versions of files. The Project Editor in -SNiFF+ is the main tool for version control.

Version tree is the hierarchical structure in which all versions of a file are organized. A version tree has one main trunk and can have several branches. The version tree is typically stored in a Repository file.

Working file is a file that has been checked out of the Repository in a working environment (usually in a Private Working Environment). A working file can be directly accessed. Each working file has a corresponding Repository file.

Working Environment is a directory tree that contains projects and working files. SNiFF+ distinguished between private and shared working environments. A shared working environment is accessed among several developers in a team and is overridden by their Private Working Environments. Shared working environments can be split into Shared Source and Shared Object Working Environments in order to separate platform-independent from platform-dependent files. Shared working environments can override other shared working environments, resulting in multiple levels of overriding working environments. The common part of overridden and overriding working environments must have the same directory structure.

Working Environments Administrator is the person who is responsible for the setup, administration and maintenance of working environments. An administrator is informed of the results of automatic updates and builds. Typically, shared working environments are administrated by experienced developers with a thorough understanding of all projects that reside in a working environment.

Working Environment root directory is the root directory of a working environment. All root projects that are located in the working environment are subdirectories of the working environment root directory. If many projects need to be managed in a working environment, groups of projects can be located in subdirectories of the working environment root directory.